The growth of Internet Protocol (IP)-based networks as carriers for various types of digital communications has led to the advent of application protocols used to negotiate and define the parameters of a communications session between two peer computing devices. One example of such an application protocol is Session Initiation Protocol (SIP), commonly used for establishing and managing Voice-over-IP (VoIP) connections. As a corollary to the introduction of application protocols like SIP, other protocols have been created to add a layer of description to enable the respective participants in a communications session to understand and share the properties and parameters (e.g., media type, IP address, transport protocol, encryption key) of the session. An example of this type of description protocol is Session Description Protocol (SDP).
The set of properties and parameters used in SDP are often called a session profile. SDP also uses attributes to extend the core session protocol. For example, attributes are defined to assign a client or server role to each peer device. A peer device with the client role initiates the connection, and the peer device with the server role waits for an initial connection establishment message from the client device.
Along with the rise of IP-based networks and digital communications has come the need to protect such networks and the devices that reside on them from security vulnerabilities and attacks. To provide for secure communications, many private communication networks connect to public networks (e.g., Internet) using a network security device, such as a firewall device, a Network Address Translation (NAT) device, or a computing device executing software that performs firewall, NAT, and/or other security functions. Generally, these types of network security devices mask the local addresses of client devices within the private network. In addition, these security devices prevent unsolicited inbound communications from reaching the client devices, for example, by requiring client devices located behind a NAT or firewall device to act as clients (e.g., initiate connections) or by not enabling the client devices located behind the NAT or fire wall device to act as servers from a transport protocol establishment perspective.
FIG. 1 is a block diagram illustrating a typical network configuration 100 for providing secure communications between private communications networks. The configuration 100 includes two client computing devices 102a and 102b, two NAT devices 104a and 104b, located within private networks 106a and 106b, respectively, which act as an interface between the client computing devices 102a and 102b and the intermediary device 108. As shown in FIG. 1, client computing device 102a in private network 106a establishes a transport connection (e.g., Transmission Control Protocol (TCP) connection) with client computing device 102b by communicating with NAT device 104a, which transmits the communication via intermediary device 108 to NAT device 104b in private network 106b and then to client computing device 102b. 
IP-based networks utilize the Internet Protocol and transport protocols like User Datagram Protocol (UDP), Stream Control Transmission Protocol (SCTP), and TCP to transfer the data between the applications on two nodes. The IP layer solves the problem of identifying and routing the packets from one node to another node. The Transport layer provides end-to-end message transfer capabilities independent of the underlying network, along with error control, segmentation, flow control, congestion control, and application addressing (port numbers). End-to-end message transmission for connecting applications at the transport layer can be categorized as either connection-oriented, implemented in TCP, or connectionless, implemented in UDP.
A frequently-used technique to provide security for such transport connections is the Transport Layer Security (TLS) protocol. Generally, TLS provides for the establishment of secure connection-oriented transport sessions on top of transport protocols such as TCP. VoIP application layer protocols such as SIP and SDP may run on top of TLS in order to provide security for those VoIP application layer protocols. Uses of the TLS protocol typically require that the role (e.g., client) assumed by a given device during the establishment of a TLS connection is the same as the role assumed by that peer device during the establishment of the underlying TCP connection.
If a device (e.g. client computing device 102a, 102b) is located behind a NAT device (e.g. NAT device 104a, 104b), it needs to act as a client from a TCP connection establishment perspective because most NAT or firewall devices do not allow through an IP packet intended to establish a new TCP connection to the client device. However, most NAT devices do allow IP packets to the client device if the IP packets are sent in the context of a TCP connection initiated by the client device. Therefore, when two devices (e.g., client computing devices 102a and 102b) connecting via TCP are located behind respective security devices (e.g., NAT devices 104a and 104b), both peer devices are forced by the security devices to assume the role of client. However, the TCP protocol prevents two devices from establishing a connection where both devices have the client role, so the intermediary device 108 is required to facilitate the TCP connection.
FIG. 2 is a flow diagram illustrating a technique for using SIP and SDP to establish a TCP media session between two client devices that are located behind NAT devices. One of the methods of establishing the TCP connection, facilitated by the intermediary device 108, is known as TCP stitching. The techniques described herein relate to the establishment of a secure transport connection (e.g., TCP media connection) for media transport. Establishing signaling connectivity needed to set up a TCP media connection can be achieved in various ways and is outside the scope of the invention.
The client computing device 102a transmits a request message (e.g., SIP INVITE 202) to intermediary device 108 via the NAT device 104a. The SDP content in the SIP INVITE message 202 specifies a TCP role (e.g., client or server) and an IP address (e.g., ‘x’) and port (e.g., ‘y’) associated with the client device 102a. The intermediary device 108 replaces the IP address and port in the SDP content of the SIP INVITE message 204 with the intermediary device's 108 own IP address (e.g., ‘ID’) and port (e.g., ‘id1’). The intermediary device 108 also sets the TCP role specified in the SIP INVITE message 204 to indicate a server role for the intermediary device 108. The intermediary device 108 then forwards the modified SIP INVITE message 204 to the client computing device 102b via the NAT device 104b. 
Upon receiving the modified SIP INVITE message 204 from the intermediary device 108, the client computing device 102b selects the role of client for establishment of the TCP media connection and transmits a response message (e.g., SIP 200 OK message 206, a SIP 183 (Session Progress) message) back to the intermediary device 108. The SDP content in the SIP 200 OK message 206 includes a TCP role indicating the client role for the client computing device 102b and an IP address (e.g., ‘a’) and port (e.g., ‘b’) associated with the client device 102b. 
The intermediary device 108 replaces the IP address and port of the SDP content in the SIP 200 OK message 208 with the intermediary device's 108 own IP address and port. The intermediary device 108 also sets the TCP role of the SIP 200 OK message 208 to indicate a server role for the intermediary device 108, and forwards the modified SIP 200 OK message 208 to the client computing device 102a via the NAT device 104a. Upon receiving the modified SIP 200 OK message 208 from the intermediary device 108, the client computing device 102a assumes the role of client for establishment of the TCP media connection. At this point, both client computing devices 102a and 102b are assigned the role of client for purposes of establishing a TCP media connection.
Both client computing device 102a and client computing device 102b transmit a TCP synchronize (SYN) message (e.g., messages 210 and 212) to intermediary device 108 because, as TCP clients, they initiate the connection. The SYN messages 210 and 212 each include an IP address and port associated with the respective client computing devices 102a and 102b from which the SYN messages 210 and 212 originated. When the SYN messages 210 and 212 pass through the respective NAT devices 104a and 104b, the SYN messages 210 and 212 are modified to include the IP address and port of the NAT devices 104a and 104b to be used for this particular NAT binding. The intermediary device 108 stores the source IP address and port, among other attributes, related to the SYN message 210 received from client computing device 102b and drops the SYN message 210.
Similarly, the intermediary device 108 stores the source IP address and port related to the SYN message 212 received from client computing device 102a. The intermediary device 108 rewrites the address fields of the SYN message 212 received from the client computing device 102a based on what the intermediary device 108 has learned from the client computing devices 102a and 102b. For example, the intermediary device 108 rewrites the source IP address and port of the SYN message 212 to be the IP address and port of the intermediary device 108 instead of the IP address and port associated with the client computing device 102a. Similarly, the intermediary device 108 rewrites the destination IP address and port of the SYN message 212 to be the IP address and port associated with the client computing device 102b. The intermediary device 108 also sets the TCP ACK bit in the modified TCP message 214 and transmits it via the NAT device 104b to the client computing device 102b. 
Upon receiving the rewritten SYN+ACK message 214 from the intermediary device 108, the client computing device 102b responds with an acknowledgement (ACK) message 216. The intermediary device 108 rewrites the IP address and port fields of the ACK message 216 to direct the message 216 to the client computing device 102a, and also adds information based on the data stored from the SYN message 210 previously received from client computing device 102b. The intermediary device 108 transmits the SYN+ACK message 218 to the client computing device 102a, and the device 102a responds with an ACK message 220. From this point forward, the TCP media connection between the client computing devices 102a and 102b is established, and the intermediary device 108 continues to rewrite the source and destination IP addresses and ports of messages that pass through the intermediary device 108 between the client computing devices 102a and 102b. 
Although TCP stitching addresses the issue of establishing TCP media connections when the two client devices are located behind network security devices such as NAT devices, TCP stitching does not provide a solution for establishing TLS connections because the TCP roles (e.g., client, server) assumed by the client devices dictate their TLS roles. Therefore, when both client devices are clients from a TCP perspective, the client devices also assume the client role from a TLS perspective. This configuration presents a conflict with the TLS connection handshake protocol because it requires that one TLS client and one TLS server establish a TLS connection. What is needed is a technique for establishing a TLS connection between two TCP client devices that are located behind network security devices without the TLS layer roles being limited to the TCP layer roles defined for each client device.